What should we do if the assignment is unreachable?

			class Foo {
				constructor(x) {
					if (x) {return}
					this.foo = 'foo';
				}
			}

What should we do if the assignment is unreachable?

It's dynamically set, so it cannot be statically defined. It should not be reported by this rule.

Hey @fregante!
Thanks for your input about the linting - is there a ruleset somewhere which I could use? The lint task in this repo is not doing this much (at least for me) and it removes some of your changes 😄 E.g. it seems that the part /** @type {import('eslint').Rule.RuleModule} */ is required by the lint task - after your change it was failing with:

So, I've reverted this one change.

Or maybe we can just agree that once the work in this PR is done you'll maybe just run your linter on it once?

Handled stopping of the static analysis on unsupported case: 3376845

Okay, I fixed all test/linting errors connected with my rule - should I fix other as well? They seems to be connected with some default options missing in already existing rules?
cc: @sindresorhus @fregante @fisker

Hey! I've merged last changes from main to the branch of this PR - now it's ready to be reviewed again

Change the test file extension from .mjs to .js.

@sindresorhus done: 8358a43

I'm not sure yet why the tests are failing - locally they're working just fine.

Okay, got it working and all of the requested changes are applied.

BTW it's weird, but for me the npm run fix:eslint-docs script worked only on node@22.
Maybe it would be good to add an .nvmrc file to the root of the repo with the node version that should be used when running npm scripts?

ready to be re-reviewed @fisker

@FRSgit Bump :)

Fixed the fix logic for some edge cases, especially

class Foo {
constructor() {
	this.bar = 1;
}
static}